home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group01b.txt / 000085_icon-group-sender_Thu Jul 5 08:57:30 2001.msg < prev    next >
Internet Message Format  |  2002-01-03  |  2KB
  1. Return-Path: <icon-group-sender>
  2. Received: (from root@localhost)
  3.     by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id f65FvRk19199
  4.     for icon-group-addresses; Thu, 5 Jul 2001 08:57:27 -0700 (MST)
  5. Message-Id: <200107051557.f65FvRk19199@baskerville.CS.Arizona.EDU>
  6. Date: Tue, 03 Jul 2001 17:44:12 -0600
  7. From: "Cheyenne Wills" <cheyenne_wills@qwest.net>
  8. To: "'icon-group@CS.Arizona.EDU'" <icon-group@cs.arizona.edu>
  9. Cc: "Art Eschenlauer" <art.eschenlauer@sufsys.com>
  10. X-Accept-Language: en
  11. Subject: Re: Software testing for Icon?
  12. Errors-To: icon-group-errors@cs.arizona.edu
  13. Status: RO
  14. Content-Length: 1443
  15.  
  16. There are many other types of languages that do not do compile time type
  17. checking (Rexx,
  18. Lisp, etc.) However there are ways of runtime checking
  19.  
  20. procedure foobar(parm1)
  21.      parm1  := integer(parm1) | stop("parm1 cannot be converted to an
  22. integer")
  23.      return parm1 * 42
  24. end
  25.  
  26. Yes.. this is defensive programming and for anything that is critical, I
  27. would 
  28. strongly suggest that defensive programming is the best bet (in fact I
  29. would 
  30. say that in today's world the lack of defensive programming is what gets
  31. a lot
  32. of people into trouble, everything from buffer overruns to not checking
  33. the 
  34. status of values returned to see the function worked or didn't).  
  35.  
  36. Cheyenne
  37.  
  38. Art Eschenlauer wrote:
  39. > 
  40. > One concern that I expect people to raise with respect to using Icon in the
  41. > "mainstream" is, "Icon cannot be trusted because it does not typecheck
  42. > arguments at compile time.  How can you protect against programmer errors in
  43. > the arguments passed during infrequently-executed invocations?"  I don't
  44. > think that the response (however true) that C++ has compile-time
  45. > type-checking and yet still is notorious for null pointer errors, etc, will
  46. > convince anybody.
  47. > 
  48. > This raises two questions in my mind regarding Icon:
  49. > 
  50. > 1. Should one adopt a "defensive programming style", always checking the
  51. > arguments passed to each routine?
  52. > 
  53. > 2. What work has been done on developing rigorous software-testing
  54. > methodology for Icon programs?
  55.